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(54) Method and apparatus for marshalling and unmarshalling argument object references 

(57) Methods and devices for reducing computing 
overhead in a distributed client/server based computing 
system which utilize an efficient framework for marshal- 
ing and unmarshaling argument object references are 
disclosed. In one aspect of the invention, a method of 
unmarshaling an argument object reference, which 
includes a subcontract identifier, that is a part of an 
argument encapsulated within a marshal buffer involves 
identifying the subcontract identifier associated with the 
argument object reference, using the identified subcon- 
tract identifier to identify an appropriate associated 
unmarshal method, and calling the associated unmar- 
shal method. In another aspect of the invention, a 
method of marshaling an argument object reference, 
which includes a subcontract identifier, that is a part of 

an argument encapsulated within a marshal buffer — 

involves invoking a marshal method of a client represen- 
tation in the argument object reference passing the mar- 
shal buffer as an argument to the marshal method. 
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Description 

CROSS REFERENCE TO RELATED APPLICATIONS 

U.S. patent Serial No. 08/554,794, entitled "Method s 
and Apparatus for Subcontracts in Distributed Process- 
ing Systems," filed 11/07/95 as a continuation to Serial 
No. 07/995.863, filed 12/21/92 (now abandoned), is 
related to the present application and is incorporated by 
reference herein in its entirety. Additionally, the following w 
U.S. patent applications, all filed concurrently herewith, 
are related to the present application and are also incor- 
porated by reference herein in their entirety: Serial No. 

- (Atty: Docket No. SUN1P079); 

Serial No. : (Atty: Docket No. is 

SUN1P078): Serial No. (Atty: 

Docket No. SUN1P082); Serial No. 

^ (Atty: Docket No. SUN1P083); 

and Serial No. (Atty: Docket No. 

SUN1P077). 20 

BACKGROUND OF THE INVENTION 

1 . Field of Invention 

25 

The present invention relates to the fields of distrib- 
uted computing systems, client-server computing, and 
object-oriented programming. More particularly, the 
invention relates to methods and devices for marshaling 
and unmarshaling argument object references to facili- so 
tate servant invocation 

2. Description of Prior Art 

A computing environment in which objects located ss 
on different computers are linked by a network is typi- 
cally referred to as a client-server computing environ- 
ment. Some of the computers act as providers of 
services or functionality to other computers. Others of 
the computers act as consumers of services or function- 40 
alities. The providers of service or functionality are 
known as "servers", and the consumers of the service 
or functionality are called "clients". The client-server 
model may also be generalized to the case where dis- 
tinct programs running on the same computer are com- 45 
municating with one another through some protected 
mechanism and are acting as providers and consumers 
of service or functionality. 

Attempts to provide such a distributed system have 
been made using object-oriented methodologies that so 
are based upon a client-server model in which server 
objects, often referred to as servants, provide interfaces 
to client objects that make requests of the server 
objects. Typically, in such a distributed system, the serv- 
ants are objects which include data and associated ss 
methods. The client objects obtain access to the func- 
tionalities of the server objects by executing calls on 
them, which calls are mediated by the distributed sys- 



tem. When the server object receives a call, it executes 
the appropriate method and transmits the result back to 
the client object. The client object and server object 
communicate through an Object Request Broker (ORB) 
which is used to locate the various distributed objects 
and to establish communications between objects. Dis- 
tributed objects may exist anywhere in a network, as for 
example in the address space of the client, in multiple 
address spaces on the client machine, and in multiple 
machines across the network. 

The software industry has responded to the need 
for a distributed object technology by forming the Object 
Management Group (OMG). The goal of the OMG is to 
define the Object Management Architecture (OMA), 
which has four major components: the Object Request 
Broker (ORB), Object Services, Common Facilities, and 
Application Objects. The Object Request Broker pro- 
vides basic object communications and management 
services, thereby forming the basis of a distributed 
object system. A standard for an Object Request Broker 
is contained in the Common Object Request Broker 
Architecture (CORBA) specification. 

In typical client-server systems, performance over- 
head can be costly. That is, the speed and quality of a 
process within the system may be compromised by inef- 
ficient uses of application code and methods associated 
with gathering information from the process or with rout- 
ing information within a process. By way of example, the 
performance overhead associated with marshaling and 
unmarshaling object references which are arguments to 
target object references, is often relatively high. As will 
be appreciated by those skilled in the art, in order to 
marshal or unmarshal an object reference, the marshal 
or unmarshal method which corresponds to the object 
reference must be identified. By way of example, the 
marshal and unmarshal functions used to marshal and 
unmarshal arguments which are simple integers, i.e. 
arguments that are of the type "integer," will differ from 
the marshal and unmarshal functions used to handle 
arguments that are of the type "string," which in turn will 
differ from the marshal and unmarshal functions used to 
handle arguments that are of the type "object refer- 
ence." 

The identification of the correct marshal or unmar- 
shal method usually involves a search of all available 
marshal and unmarshal methods. The performance 
overhead associated with these searches is typically 
relatively high. In particular, the performance overhead 
associated with identifying the marshal and unmarshal 
methods associated with argument object references is 
often high due to the fact that the argument object refer- 
ence must first be identified as being of the type "object 
reference," and then a search must be made for an 
appropriate marshal or unmarshal method. In a distrib- 
uted object system which utilizes a variety of different 
transport mechanisms and protocols, there will typically 
be many encoding formats, i.e. marshal methods, for 
use in encoding object references. Similarly, there may 
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be many decoding formats, i.e. unmarshal methods; for 
use in decoding encoded object references. As such, a 
search for an appropriate marshal and unmarshal meth- 
ods may very likely require a relatively high amount of 
computing overhead. High performance overhead often 5 
results in an inefficient use of system resources. Conse- 
quently, the provision of methods and devices which 
would reduce the performance overhead associated 
with marshaling and unmarshaling argument object ref- 



erences is desirable. 



SUMMARY OF THE INVENTION 



w 



To' achieve the foregoing and other objects and in 
accordance with the purpose of the present invention, is 
methods and devices for reducing computing overhead 
by utilizing an efficient framework for marshaling and 
unmarshaling argument object references in a distrib- 
uted client/server based computing system are dis- 
closed. In one aspect of the invention, a method of 20 
unmarshaling an argument object reference, which 
includes a subcontract identifier, that is a part of an 
argument object reference encapsulated within a mar- 
shal buffer is disclosed. The marshal buffer provides the 
ability to identify the subcontract identifier embedded in 25 
an argument object reference encapsulated within the 
marshal buffer. The identified subcontract is then used 
to identify an associated unmarshal method. Once an 
appropriate unmarshal method is identified, the appro- 
priate unmarshal method is called. 30 

In one preferred embodiment, the detected subcon- 
tract identifier is compared to an expected subcontract 
identifier. When it is determined that the identified sub- 
contract identifier is the same as the expected subcon- 
tract identifier, predefined expected unmarshal method 35 
that corresponds to the expected subcontract identifier 
is called. When the identified subcontract identifier is 
not the same as the expected subcontract identifier, a 
subcontract registry is accessed in order to identify the 
appropriate unmarshal method. 40 

In another aspect of the invention, a method of mar- 
shaling an argument object reference is disclosed. This 
is accomplished by invoking a marshal method of a cli- 

_entxepies_entatio^ 

erence and passing the desired marshal buffer as an 45 
argument to the marshal method. A client representa- 
tion represents an ORB object and implements the cli- 
ent side functionality and features of the subcontract 
associated with the object, including marshaling an 
object reference to the object as an argument. If the so 
subcontract identified by the subcontract identifier in the 
argument object reference is known, the argument 
object reference is encoded into a form appropriate for 
the identified marshal buffer type. In some embodi- 
ments, if the argument object reference may be ss 
encoded into a form appropriate for an identified mar- 
shal buffer type, the marshal method marshals the argu- 
ment object reference into the marshal buffer. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The invention, together with further advantages 
thereof, may best be understood by reference to the fol- 
lowing description taken in conjunction with the accom- 
panying drawings in which: 

FIG. 1a is a symbolic overview of a distributed 
object system suitable for implementing the present 
invention. 

FIG. 1b is a diagrammatic illustration which repre- 
sents how a request by a client is routed through 
the architecture of a client side and a server side of 
a distributed object system, and the interface 
between the client side and the server side of the 
distributed object system. 

FIG. 1c is a diagrammatic representation of data 

fields present in an object reference suitable for use 

in inter-process invocations in accordance with one 

embodiment of the present invention. 

FIG. 2 is a process flow diagram which illustrates a 

method of invoking an object in accordance with 

one embodiment of the present invention. 

FIG. 3 is a process flow diagram which illustrates a 

method of executing a remote stub, i.e. step 115 of 

FIG. 2. in accordance with one embodiment of the 

present invention. 

FIG. 4 is a process flow diagram which illustrates a 
method of calling an invoke method using a remote 
stub, i.e. step 196 of FIG. 3, in accordance with one 
embodiment of the present invention. 
FIG. 5 is a process flow diagram which illustrates 
steps that occur on the server side of a distributed 
object-oriented system once a request is received 
on a receiving end point in accordance with one 
embodiment of the present invention. 
FIG. 6 is a process flow diagram which illustrates a 
method of marshaling argument object references, 
i.e. one case of step 210 of FIG. 4, in accordance 
with one embodiment of the present invention. 
FIG. 7 is a process flow diagram which illustrates a 
method of unmarshaling an argument object refer- 
ence, i.e. one case of step 222 of FIG. 4, in accord- 

ance with one embodiment of the present invention^ — 

FIG. 8 is a process flow diagram which illustrates a 
method of implementing a subcontract specific 
unmarshal routine to create an object reference, i.e. 
step 330 of FIG. 7, in accordance with one embod- 
iment of the present invention. 
FIG. 9 is a diagrammatic representation of a sub- 
contract registry in accordance with one embodi- 
ment of the present invention. 
FIG. 10 illustrates a typical computer system in 
accordance with one embodiment of the present 
invention. 
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DETAILED DESCRIPTION OF THE INVENTION 

The present invention is directed toward distributed 
object systems and will be described with reference to 
several preferred embodiments as illustrated in the 5 
accompanying drawings. The invention may be prac- 
ticed within the context of any suitable distributed object 
system, including those defined under CORBA or any 
other suitable specification. However, for purposes of 
illustration, the present invention will be described pri- 10 
marily within the context of an Object Request Broker 
(ORB) implemented under the CORBA specification 
from the OMG, Revision 2.0, dated July 1995, which is 
incorporated herein by reference. FIG. 1a diagrammati- 
cally illustrates the overall architecture of a representa- is 
tive distributed object system suitable for implementing 
the present invention. FIG. 1b diagrammatically illus- 
trates some possible flow paths that a request from a cli- 
ent to a servant object may follow within such an 
architecture that includes a three level dispatch mecha- 20 
nism. FIG. 1c shows one object reference data structure 
that may be used by a client to refer to a servant object. 

A distributed object system 10 typically includes an 
Object Request Broker (ORB) 11 as is symbolically 
illustrated in FIG. 1a. ORB 1 1 provides all of the location 25 
and transport mechanisms and facilities necessary to 
deliver a call from a client to a servant (target object) 
and to return a response to the client, as will be dis- 
cussed below with reference to FIG. 1b. The client and 
servant may be located in the same process, in different 30 
processes on the same machine, or on completely dif- 
ferent machines. For the purposes of this discussion, 
client 20 may be any code that invokes an operation on 
a distributed object and thus may or may not take the 
form of distributed object or a process. Normal object 35 
implementation 14 is a representation of an object type 
defined in a traditional object programming language, 
such as C++. A wide variety of representations are pos- 
sible. By way of example, an object implementation 14 
may be a simple C++ object type that has been pro- 40 
vided by an application developer. Alternatively, an 
implementation for an object type may be developed 
within a visual application builder 15. This visual appli- 
cation builder allows a developer to visually select exist- 
ing object types from a catalog and graphically connect 45 
the services provided by one object to the services 
needed by another (attributes, arguments, etc.) in order 
to create a new implementation for an object type. 

An object development facility 16 may be used to 
simplify the creation and the installation of distributed so 
objects. It is used to "wrap" or encapsulate developer 
objects in distributed object code. As such, object devel- 
opment facility 1 6 may be used to transform a developer 
object into an ORB object implementation 14. In this 
example, ORB object implementation 14 is presented ss 
as a server as shown by its location in the diagram. A 
developer uses an interface definition language to 
define an interface for an ORB object, provides a devel- 



oper object implementation that implements that 
object's behavior, and then uses the object develop- 
ment facility in order to produce an ORB object imple- 
mentation 14. At run time, an instance of this ORB 
object (a servant object) is created that will utilize this 
ORB object implementation 14. It should be appreciated 
that the object development facility may also be used to 
create objects that take the role of clients at some point. 

Client 20 communicates with a servant by way of a 
stub 21 , a subcontract layer 36, possibly a filter 40, and 
a transport layer 38. Stub 21 includes a surrogate 22. a 
method table 24, and a stub function 25. Client 20 com- 
municates initially with surrogate 22 which appears to 
the client as the server object. Alternatively, client 20 
may communicate directly with the server object 
through a dynamic invocation interface (DM) 26 instead 
of through surrogate 22, method table 24, and stub 
function 25. Dynamic invocation interface 26 is used to 
enable clients, as for example client 20, to construct 
dynamic requests. One procedure by which a client 
makes a call to a servant utilizing the above layers is 
described in more detail below with reference to FIG. 
1b. 

Subcontract layer 36 provides the functionality 
required by an object in order to utilize subcontracts to 
implement various services (or features or object mech- 
anisms) named by a particular subcontract. A subcon- 
tract identifies a quality of service provided by the 
distributed object system that may be utilized by an indi- 
vidual object. For example, a subcontract may identify 
that the feature of security is to be used for a particular 
object. Filter 40, if being used, may perform a variety of 
tasks, such as compression, encryption, tracing, or 
debugging, which are to be applied to communications 
to and from an object. 

Transport layer 38 operates to marshal, unmarshal 
and physically transport information to and from a serv- 
ant that typically does not share the same process as a 
client. 

A standard implementation suite 28 (or object 
adapter) represents a set of subcontracts that interact 
with ORB objects 14 tn fdenfccai ways, as for example 
object key management, tt should be duly noted that a 
subcontract may belong to multiple implementation 
suites. Hence, other implementation suites that utilize 
different subcontracts are possible. A skeleton, which 
may take the form of either static skeleton 32 or 
dynamic skeleton 30 is used to transform requests into 
a format required by a servant object 14. Thus, skele- 
tons 32, 30 call an appropriate servant object 14. Static 
skeleton 32 is used to call interface-specific object 
implementations 14, while dynamic skeleton 30 is used 
genetically when interface-specific objects are not avail- 
able. An ORB Daemon 46 is responsible for ensuring 
that object servers are active when invoked by clients. 

Secure Protocol 42 is a secure interoperability pro- 
tocol that secures the internet inter-ORB protocol and 
helps to transmit information through transport layer 38 
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in a secure fashion. This may mean integrity protection, 
confidentiality, etc. The internet inter-ORB protocol is a 
protocol that typically communicates between proc- 
esses on different machines. However, in some cases, 
the internet inter-ORB protocol may communicate 
between process on the same machine. The security 
server 54 is a security administration server that 
secures the services that are used between processes 
on different computers. 

Typecode/Any module 44 implements typecode 
and "Any" objects. Typecode describes an Interface 
Definition Language (IDL) data type, allowing type 
descriptions to be transmitted between clients and serv- 
ers. An instance of an IDL data type may be encapsu- 
lated by an "Any" object. An Any object refers to 
typecode of the encapsulated data, and a generic 
encoding of the data. 

An implementation repository 50 is used to store 
information relating to object servers. Specifically, 
implementation repository 50 stores the information 
needed to start a server process. For example, imple- 
mentation repository 50 stores information such as the 
location of the server program, any arguments to the 
program, and any environment variables to pass to the 
program, etc. 

Simple persistence 56 uses an Interface Definition 
Language (IDL)-defined type and the output from run- 
ning that IDL type through the IDL compiler, together 
with a portion of additional code so that an IDL-defined 
type can be read from, and written to, disk. A name 
server 52 is used to name ORB objects. A client, as for 
example client 20, may use name server 52 to find a 
desired object by name. Name server 52 returns an 
object reference, which in turn may be used to send 
requests to that object. An Interface Repository 48 (IFR) 
knows about all interfaces for all objects within the dis- 
tributed object system. 

A request made by a client using a method table 
("m-table") dispatch will pass through a variety of the 
aforementioned layers of the architecture on its way to 
the servant as diagrammatically illustrated in FIG. 1b. 
The request is initiated by a client and may take any 
suitable form. The form of the request will depend to a 
larg e extent upon th e na ture of t he p r ogramming lan^ 
guage used to create the client. By way of example, if 
the client is written in the C++ language, the request 
may take the form of a C++ method call 62. The call is 
made to a designated object reference taking the form 
of a surrogate. The surrogate includes methods that 
comply with the object's interface. As will be appreci- 
ated by those skilled in the art, the object reference 
used at different locations within a distributed object 
system may vary significantly in appearance. In the 
embodiment described, the client side object reference 
is a dual pointer (referred to herein as a "fat pointer"). A 
fat pointer contains two distinct pointers. A first pointer 
points to a client representation ( "client rep") associated 
with the referenced object. A second pointer points to a 



method table of the method table dispatch 24 that is 
associated with the referenced object. A client repre- 
sentation is an object that has methods which support 
invocation as well as CORBA defined "pseudo" object 
5 reference operations. These operations include, but are 
not limited to, a duplicate method, a release method, a 
narrow method, a hash method, and an is_equivalent 
method. 

Alter the client has initiated a call, the call is proc- 

w essed using a method table dispatch mechanism 24. 
The method table dispatch mechanism uses a method 
table that contains a list of pointers to stub functions 25, 
one of which is associated with the method to be 
invoked. Stub functions 25 receive a function or proce- 

15 dure call in the "native" language of the client process, 
then use either a subcontract layer 36 or a native call to 
eventually call the corresponding servant object. The 
native language may be any suitable language, as for 
example a language such as C++. 

20 Method table dispatch 24 determines the appropri- 
ate stub function 25 to process the method call, and 
then pairs the method call with the appropriate stub 
function 25. In the event that the client making the 
method call is in the same process as the servant 

25 object, a local stub function is called. The local stub 
function sends the method call directly to servant object 
78. Alternatively, if the servant object is in a different 
. process, i.e. a remote process, a remote stub function is 
called. The remote stub function invokes the client rep- 

30 resentation, which delivers the invocation to servant 
object 78. 

Subcontracts implemented by subcontract layer 36 
are logic modules which provide control of the basic 
mechanisms of object invocation and argument passing 
35 that are important in distributed object systems. A sub- 
contract implemented by subcontract layer 36 deter- 
mines a specific quality of service for use by an object. 
A subcontract is uniquely identified by a subcontract 
identifier, which is typically embedded in an object refer- 
ee ence. A quality of service is a set of service properties. 
Among possible service properties which are selectable 
are qualities relating to server activation, security, trans- 
actions, filterability, and clean shutdown. Subcontracts 
- - are conf igured such that certain qualitiesof-service-are- 
45 available. With predetermined qualities of service, the 
overhead associated with processing individual service 
properties is reduced. Realistically, only "reasonable" or 
commonly used combinations of service properties are 
supported with subcontracts. However, subcontracts 
so may be created to meet the specific requirements of a 
given distributed object system. 

The identification of an appropriate subcontract in 
subcontract layer 36 may be thought of as the identifica- 
tion of a desired function that is unique to that subcon- 
55 tract. For example, a marshal function or an unmarshal 
function is defined for each subcontract. A subcontract 
marshal function is used by a stub to marshal an object 
reference so that it may be transmitted .to another 
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address space, or domain. The object reference is typi- 
cally processed by a transport mechanism in transport 
layer 38. 

A transport mechanism such as T1, T2, etc.. which 
is a part of the transport layer 38, is used to marshal and 
physically transport information to and from servant 
objects. Information, i.e. the object reference or the 
request, is converted into protocols appropriate to a 
given domain. By way of example, protocols may 
include, but are not limited to, Ethernet protocols and 
internet interoperable protocols (IIOPs). In some 
uncommon cases, protocols may even entail the use of 
electronic mail to transmit instructions to be imple- 
mented on a server. After information is marshaled, the 
transport mechanism then transports information 
through any combination of an operating system, a 
device driver, or a network, that are all a part of hard- 
ware 70 used by the client side of a distributed object 
system. While transport mechanisms require a conver- 
sion of information into a protocol appropriate to a given 
domain, some transport mechanisms to do not require 
the encoding of information for different domains. One 
transport mechanism which does not require a conver- 
sion of information into a protocol appropriate to a 
domain other than the one on which information origi- 
nates is termed a "door". Doors are essentially gate- 
ways between two different processes on the same 
host. The use of doors eliminates the need for a conver- 
sion of information into a canonical implementation in 
transport layer 38, as there is no need to encode infor- 
mation into a protocol which may be used by a different 
machine by virtue of the fact that information is remain- 
ing on the same host and therefore does not require a 
change of domain. Hence, information may simply be 
"flattened out/' or marshaled into a stream which is not 
encoded for use by a different machine, and passed 
between the two processes on the host. 

Once information is transported through hardware 
70 used by the client side, the information is then trans- 
ported to hardware 70 on the server side of a distributed 
object system. Once information is routed through hard- 
ware 70, the server side of a distributed object system 
invokes a transport mechanism such as T1, T2 etc. to 
receive information on an end point which is a part of 
transport layer 38. In the event that an end point is not 
created by transport layer 38, transport layer 38 pro- 
vides the functionality needed for the end point to be 
created by subcontract layer 36. By way of example, a 
door end point is typically created by subcontract layer 
36, while other end points, including network and 
TCP/IP end points, are typically created by transport 
layer 38. Regardless of whether end points are created 
by subcontract layer 36 or transport layer 38, end points 
live in," i.e. are a part of, transport layer 38. End points 
are essentially ports which receive information from a 
different domain. After an end point in transport layer 38 
receives information transported from a different 
domain, the end point then dispatches the information 



from transport layer 38 to subcontract layer 36. Subcon- 
tract layer 36, or more specifically the subcontract in 
subcontract layer 36 which receives the information, 
then dispatches the information to the skeleton and the 
5 servant. 

Subcontract layer 36 provides the functionality to 
unmarshal at least some of the information it has 
received. That is, subcontract layer 36 unmarshals at 
least part of the request. Then, the request is dis- 

to patched to a skeleton 31 which transforms the request 
into an implementation specific format required by serv- 
ant object 78. The skeleton may either be a static skele- 
ton or a dynamic skeleton as described above. 

In general, a remote request must be routed 

is through the client side and the server side as described 
above. The method call 62 is received, method table 
dispatch layer 24 is used to identify an appropriate sub- 
contract prior to the selection of a transport mechanism 
in transport layer 38 which marshals the request and 

20 prepares it for transport to another domain. Through 
hardware 70, the marshaled request is transposed to 
the server side where it is received on an -nu ooint 
which is a part of transport layer 38. An appropriate end 
point receives information transported across a wire, 

25 and information is dispatched from transport layer 38 to 
subcontract layer 36, which provides the functionality to 
at least partially unmarshal the information it has 
received. The subcontract then dispatches the request 
to skeleton 31 which transforms the request into a spe- 

30 cific format required by servant object 78. This path is 
shown by arrow 77, and is the path which may be taken 
by both remote and local requests. 

However, if a client and a server are in a local proc- 
ess, i.e. both the client and the server are in the same 

35 process, the use of the path shown by arrow 77 as 
described above is unnecessarily complex. If it is known 
that the client and the server are in the same process, it 
is possible to shorten the invocation, or flow, path of a 
request for service. If a local process may be identified 

40 when an object reference is created, shortened flow 
paths, i.e. the paths represented by arrows 75 and 76, 
may be taken to send a request from what is a client to 
a server which are on the same host. The path repre- 
sented by arrow 76 is more likely to be taken, as it uses 

45 subcontract layer 36 to identify an appropriate subcon- 
tract. However, in situations in which an appropriate 
subcontract does not need to be explicitly identified, the 
path represented by arrow 75 may be taken. 

FIG. 1c will now be used to describe an embodi- 

50 ment of an object reference. As will be familiar to those 
skilled in the art, object references may take a variety of 
forms depending upon the location within the process 
that they are being held at any given time. However, by 
way of background, a representative object reference 

55 for use in a system which utilizes a low overhead object 
adapter is illustrated in Figure 1c. In the implementation 
shown therein, object reference 150 includes a host 
identifier 152, a port designation 154, and an object key 



6 



1 1 



EPO 817 022 A2 



12 



156. Object key 156 includes a subcontract identifier 
158. a server identifier 160, an implementation identifier 
162, and a user key 164. Host identifier 152 denotes a 
particular computer in a network, while port designation 
154 identifies the port of the selected computer which is 5 
to be used for communication. Object key 156 provides 
further identifying information used in order to locate a 
desired servant object on its host machine. 

Server identifier 160 names a particular process or 
program in which the servant object resides, while user w 
key 164 is a unique number or string used to locate the 
servant within the process named by server identifier 
1 60. Subcontract identifier 1 58 is used to attach the pro- 
tocol of a particular subcontract and its associated serv- 
ices with a servant and implementation identifier 162 15 
names an implementation of an interface that is to be 
used with that servant object. 

As will be appreciated by those skilled in the art, 
when passing calls to distinct processes, it is necessary 
to identify marshal functions to use in order to encode 20 
each of the elements of the call for transfer to a different 
domain. As pointed out above, the marshaling function 
used to marshal an object reference is dependent upon 
the type of the object reference. Similarly, when receiv- 
ing object references from distinct processes, it is nec- 25 
essary to identify unmarshal functions to use in order to 
decode object references received from a different 
domain. Different types of object references are com- 
monly associated with different types of marshal and 
unmarshal functions. By way of example, the marshal 30 
and unmarshal functions used to marshal and unmar- 
shal arguments which are simple integers, i.e. argu- 
ments of type "integer," will differ from the marshal and 
unmarshal functions used to handle strings, i.e. argu- 
ments of type "string. " Likewise, the marshal and 35 
unmarshal functions used to handle arguments that are 
of the type string will be different from the marshal and 
unmarshal functions used to handle arrays, etc. 

Maintaining the overhead associated with perform- 
ing operations in a distributed object-oriented system, 40 
i.e. a distributed operating environment, at a relatively 
lower level without compromising the performance of 
the system is an important design goal in order to pro- 

vide a decent level of over all efficienc y i n the system. 

One way to reduce the overhead associated with per- 45 
forming operations is to eliminate the need to search all 
types of marshal or unmarshal functions to find the 
appropriate function to use in order to marshal or 
unmarshal, respectively, an object reference which is 
passed as an argument to a target object reference. By so 
using the marshal method of the client representation 
associated with the argument object reference, a global 
search for an appropriate marshal method may be 
avoided. Hence, the performance overhead associated 
with a search for a marshal method may be reduced, if 55 
not eliminated. In the distributed object-oriented system 
described above with respect to FIG. 1a, the use of sub- 
contracts makes it possible to reduce the performance 



overhead associated with identifying the appropriate 
unmarshal method to use to unmarshal an argument 
object reference, as each subcontract has an unmar- 
shal method with which it is associated. By identifying 
the subcontract associated with the argument object 
reference, the appropriate unmarshal method for use in 
unmarshaling the argument object reference may be 
explicitly identified. In general, the overall efficiency of a 
distributed object-oriented system may be improved by 
invoking a marshaling and unmarshaling framework 
which reduces the performance overhead associated 
with searching for marshal and unmarshal methods for 
use in marshaling and unmarshaling, respectively, argu- 
ment object references. 

Referring next to FIG. 2, a method of invoking an 
object in accordance with one embodiment of the 
present invention will be described. That is, the steps 
which occur once a call is made to an invoke method 
are shown in the diagram. Initially, a call or a request, 
which uses an object reference, is received by a client. 
Although the call may be in any suitable computer lan- 
guage, in the described embodiment, the call is a C++ 
call. The object reference in the described embodiment 
is a fat pointer. A fat pointer may be thought of as a 
"large" pointer, or a pointer structure, which contains at 
least two "normal" pointers A fat pointer may also be 
considered to be a CORBA object reference. In a fat 
pointer with two "normal" pointers, the fat pointer typi- 
cally contains eight bytes, while the normal pointers typ- 
ically contain four bytes each. The fat pointer is 
comprised of a representation pointer "rep" and a 
method table, or m-table, pointer, each of which is a nor- 
mal pointer. The representation pointer points to a client 
representation, or client "rep", and may be considered 
to be a pointer to a subcontract object that represents 
the servant object on the client. The subcontract object 
provides the features and functionality required to 
invoke the servant from the client. It should be appreci- 
ated that a client representation represents an ORB 
object and may be used to implement the client-side 
functionality and features of the subcontract associated 
with the object, including such functions as marshaling 
an object reference to the object as an argument. 
_ In step 100, the called method is located in the m- 
table pointed to by the fat pointer. If the called method is 
a local method, then the m-table pointed to by the fat 
pointer is a local m-table. Similarly, if the called method 
is a remote method, then the m-table pointed to by the 
fat pointer is a remote m-table. In step 105, a call to the 
function pointed to with the client representation identi- 
fied by the object reference (a fat pointer in the 
described embodiment) and arguments to the call is 
made. After the function is called, process control 
branches off to different functions depending upon 
whether the function pointed to is in a local process or a 
remote process. If the function pointed to is in a local 
process, process control proceeds to step 1 10 in which 
a local stub function is executed. Herein, the term "local 
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stub" will be used to refer to a "local stub function," while 
the term "remote stub" will be used to refer to a "remote 
stub function." After the local stub has been executed in 
step 110, the process returns from the function call in 
step 120. If the function pointed to by the fat pointer is in 
a remote process and not in a local process, process 
control advances to step 115 after the function is called 
in step 105. In step 1 15. a remote stub is executed. The 
process of executing a remote stub will be discussed in 
more detail below. After the remote stub has been exe- 
cuted in step 1 15, process control proceeds to step 1 20, 
which is the return from the function call. 

Referring next to FIG. 3, a method of executing a 
remote sti :c in accordance with one embodiment of the 
present in ntion will be described. That is, with refer- 
ence to FV. :■ 2, step 115, the step of executing a remote 
stub, will be described in more detail. The start of invo- 
cation from a remote stub with a list of arguments and a 
context, if a context is used, begins at step 190 which is 
the allocation of storage, or memory, for return and out 
parameters, or parameters with a return processing 
direction and parameters with an out processing direc- 
tion. A context is, in general, an array of associated 
strings containing information which is relevant to the 
method to be invoked. In some embodiments, as for 
example the C++ embodiment, in storage allocation 
step 1 90, storage is not allocated for parameters with an 
inout processing direction, as storage is preallocated by 
the caller for parameters with an inout processing direc- 
tion. After storage is allocated, parameters with an in 
processing direction, i.e. in parameters, are set up in 
step 192. Each time an invoke method is called, the in 
parameters associated with arguments used in the invo- 
cation from the remote stub must be set up. Setting up 
in parameters entails building a parameter storage loca- 
tion descriptor pointed to by the IN_PARAM identified in 
the list of arguments used at the start of invocation from 
a remote stub. Parameter storage location descriptors 
contain pointers to memory locations where parameters 
reside. After in parameters are set up, out parameters, 
as well as return parameters, are set up in step 194. 
That is, a parameter storage location descriptor contain- 
ing pointers to out and return parameter storage loca- 
tions is constructed. The method used to set up out 
parameters is analogous to the method used to set up in 
parameters. 

From step 194, the step of setting up out parame- 
ters, process control moves to step 1 96 in which a call is 
made to the invoke method for the client representation. 
Each client representation has an associated invoke 
method. The steps involved with calling the invoke 
method for the client representation will be discussed 
below with reference to FIG. 4. In step 197, a determi- 
nation is made regarding whether the call to the invoke 
method in step 196 has resulted in an exception. If it is 
determined that there has been an exception, process 
control proceeds to step 198 where the memory which 
was allocated for the storage of return and out parame- 



ters in step 190 is deallocated. Process control then 
returns the result of the call to the invoke method. If it is 
determined in step 197 that there has been no excep- 
tion, process control simply returns the result of the call 

5 to the invoke method. In some embodiments, allocated 
memory may be released before the call returns. In 
other embodiments, allocated memory may be released 
immediately after the call returns. 

Referring next to FIG. 4, a method of calling the 

re invoke method of a client representation using a remote 
stub in accordance with one embodiment of the present 
invention will be described. That is, with reference to 
FIG. 3, step 196, the step of calling an invoke method 
for the client representation, will be described in greater 

J5 detail. The process begins at step 201 where the 
remote stub calls the invoke method of the client repre- 
sentation, using descriptors, namely the method 
descriptor, the invocation descriptor, the parameter stor- 
age location descriptor or descriptors, and the excep- 

20 tion descriptor, as arguments. In other words, the 
remote stub invokes an appropriate subcontract using 
descriptors as arguments. In step 202, a transport is 
selected. If a subcontract only supports one transport, 
that transport is selected. If the subcontract has multiple 

25 transports, metrics associated with the transports pro- 
vide information which specifies the most appropriate 
transport to select. Once a transport has been selected, 
an end point is identified, based upon a target object ref- 
erence, in step 204. An end point is a "porthole ", or con- 

30 nection, which is used to receive invocations and send 
messages. The identification of an end point may either 
occur in the transport layer of a client or in the subcon- 
tract layer of the client. After an end point is identified, a 
marshal buffer appropriate for the transport selected in 

35 step 202 is created in step 206. The selection of a mar- 
shal buffer occurs in the transport layer of the client 
side. A marshal buffer is essentially a network buffer 
which encapsulates information which is to be trans- 
ported, and has the capability of encoding atomic data 

40 suitable for transport. A marshal buffer has an identifier 
or tag which specifies the type of protocol data encoding 
it performs. That is, a marshal buffer is transport, or 
transport protocol: specific, as a transport usually 
implies a particular protocol which determines the type 

45 of data encoding performed by the marshal buffer. It 
should be appreciated that many transports may have 
the same protocol, and, therefore, use the same mar- 
shal buffer type. A subcontract is able to identify the 
marshal buffer appropriate for the selected transport by 

so virtue of the identifier. 

After the marshal buffer appropriate for the selected 
transport is created, in step 208, the target object refer- 
ence and the operation, or method description, are mar- 
shaled. Only the portions of the target object reference 

55 which cannot be derived otherwise are marshaled in 
this step. Usually, only the object key is marshaled. In 
step 209. if a context is used, the context is marshaled. 
Only the information in the context which is of interest to 
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the invoke method is picked out. From the step of mar- 
shaling the context, process control moves to step 210 
where arguments are marshaled using descriptors. In 
the event that the object reference was passed as one 
of the arguments, it will be marshaled by the client rep- 5 
resentation associated with the target object reference. 
The process of marshaling argument object references 
will be described below with respect to FIG. 6. It should 
be appreciated that the order in which the context and 
the arguments are marshaled may be reversed. In some w 
cases, when no context is used, step 209 may not occur 
at all, as there is clearly no need to marshal a context if 
a context is not used. 

After the context and the arguments are marshaled, 
process control proceeds to step 212 where the con- 15 
tents of the marshal buffer are transmitted over the 
selected transport to the identified end point. For most 
selected transports, this step entails sending the con- 
tents in the marshal buffer over a wire. Transmission 
step 212 may be interpreted as the step of communicat- 20 
ing from the client to the server. From transmission step 
212, process control moves to step 21 4 where the client 
waits for a reply from the server. In a step 216, the client 
receives a reply from the server and encapsulates the 
reply in a marshal buffer. If the reply is larger than the 25 
request, a new marshal buffer may be created in order 
to encapsulate the reply. However, if the reply is not 
larger than the request, the marshal buffer created in 
step 206 may be used to encapsulate the reply in step 
216. 30 

Once the reply is encapsulated in a marshal buffer, 
a transport specific header is unmarshaled from the 
reply which is encapsulated in the marshal buffer in step 
220. A transport specific header contains information 
which pertains to the transport selected in step 202. 35 
Other headers include headers which identify argu- 
ments and headers which specify request identifiers. A 
pointer associated with the marshal buffer may be used 
to determine the beginning and the end of a header 
which is being read. This pointer moves from byte to 40 
byte in the marshal buffer as data are decoded from the 
marshal buffer. After the transport specific header is 
unmarshaled from the reply, process control proceeds 
to step 222 where arguments are unmarshaled using 
descriptors from the original call. If the arguments 45 
include argument object references, the argument 
object references may be unmarshaled using informa- 
tion provided by an OUT_PARAM descriptor associated 
with the invocation descriptor. The unmarshaling of 
argument object references will be discussed below so 
with respect to FIG. 7. After the arguments are unmar- 
shaled using descriptors, the process returns to the 
remote stub. 

The server side of a distributed object-oriented sys- 
tem responds to requests which are received on end 55 
points. Requests are typically transmitted as contents of 
a marshal buffer. The contents of a marshal buffer may 
be transmitted over a wire to an end point which 



receives the contents of the marshal buffer. As 
described above with respect to FIG. 1b, two types of 
end points are a dedicated end point and a cluster end 
point. A dedicated, or singular, end point is associated 
with a single subcontract. Hence, a dedicated end point 
always "knows" which subcontract to utilize. The func- 
tionality needed to create a dedicated end point is pro- 
vided by the transport layer, whereas the dedicated end 
point itself is actually created by the subcontract layer. A 
cluster end point, on the other hand, may be used by 
more than one subcontract, and is created in the trans- 
port layer. The subcontract layer creates transport spe- 
cific closures to be associated with the cluster end 
points. Closures are structures which include a pointer 
to a function and a pointer to a cookie, which is a pointer 
to a data element. An example of a cluster end point is 
a network or TCP/IP end point. In general, dedicated 
end points receive and process information faster than 
cluster end points as the use of dedicated end points 
requires less computation. As the use of dedicated end 
points may result in the use of more resources than 
desired for demultiplexing processes, however, cluster 
end points may be utilized in order to save resources. 

Referring next to FIG. 5, a process flow diagram 
which illustrates steps that occur on the server side of a 
distributed object-oriented system once a request is 
received on a particular receiving end point in accord- 
ance with one embodiment of the present invention will 
be described. A marshal buffer specific to the request is 
created in step 250 in order to encapsulate the received 
request. The type of marshal buffer created is deter- 
mined by the end point which is receiving the request. A 
subcontract level dispatch routine based upon the end 
point type and target object reference is selected in step 
252. A subcontract level dispatch routine is also known 
as a transport-to-subcontract closure dispatch. The 
associated subcontract and transport may also be fac- 
tors in the choice of a subcontract level dispatch routine. 
By way of example, the subcontract level dispatch rou- 
tine may be selected through the use of an end point 
specific dispatch registry which associates subcon- 
tracts with closures, each of which contains a pointer to 
a subcontract level dispatch routine. After a subcontract 
level dispatch routine is selected J n_ step 252,_prp_cess__ 
control moves to step 254 where the subcontract level 
dispatch routine selected in step 252 is called. The mar- 
shal buffer created in step 250 is passed, along with a 
"cookie", into the call to the subcontract level dispatch 
routine. A cookie is a pointer to a data element and is 
contained within a closure. 

The subcontract level dispatch routine is both trans- 
port and subcontract specific. The subcontract level dis- 
patch routine unmarshals the header of a request to 
determine the object and the method to be invoked. Typ- 
ically, in order to determine the object, the object key 
must be unmarshaled from the request header. Other 
information, as for example transaction and security 
information, which may be required by the subcontract, 
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may also be unmarshaled. A server invocation object 
appropriate for the subcontract contains information 
regarding the method to be invoked. 

In addition to unmarshaling the header of a request, 
the subcontract level dispatch routine is also locates an 
appropriate skeleton dispatch closure using the object 
key unmarshaled from the header. The subcontract 
level dispatch routine invokes the method in the skele- 
ton closure which executes the skeleton code for the 
invoked method. This skeleton method provides param- 
eter typing information by setting the invocation descrip- 
tor pointer in the server invocation object. The 
invocation descriptor is associated with descriptors 
which describe in and out parameters used in an invo- 
cation. 

The skeleton dispatch method invokes an unmar- 
shal method on the server invocation object to unmar- 
shal in parameters, using information provided in an 
associated parameter descriptor. It should be appreci- 
ated that some in parameters may be argument object 
references. After the unmarshal method is invoked to 
unmarshal in parameters, the called method of the serv- 
ant object is invoked. If the called method of the servant 
object returns normally, i.e. there are no errors in the 
invocation of the called method, the called method 
invokes the marshal method of the server invocation 
object which then marshals any return parameters and 
out parameters specified in associated return and out 
parameter descriptors. Again, it should be appreciated 
that some of the return and out parameters may be 
argument object references. The skeleton dispatch 
method may return to the subcontract level dispatch 
routine which may then perform additional subcontract 
specific processing before returning to the caller. 

Referring next to FIG. 6, a method of marshaling 
argument object references, i.e. one case of step 210 of 
FIG. 4, in accordance with one embodiment of the 
present invention will be described. In this case, an 
object reference is a fat pointer, or a dual pointer with 
pointers to a method table (m-table) and a client repre- 
sentation. In order to marshal an object reference that is 
one of or part of arguments in a call to an invoke 
method, the marshal method of the client representation 
in the argument object reference is called, with the mar- 
shal buffer passed as an argument in a step 303. The 
marshal method which is called is dependent upon the 
subcontract associated with the argument object refer- 
ence due to the fact that the associated client represen- 
tation is created using code which is specific to the 
subcontract of the servant object. Different client repre- 
sentations created by different subcontracts have differ- 
ent marshal methods, and each subcontract may 
encode different information in its marshaled object ref- 
erence. Herein, the term "argument object reference" 
will be used to refer to object references that are argu- 
ments, whereas the term "target object reference'' will 
be used to refer to object references which identify a tar- 
get object to be invoked. Parameter descriptors, as well 



as other descriptor data structures, i.e. descriptors, 
include method descriptors, invocation descriptors, and 
exception storage location descriptors. 

After the marshal method is invoked, the marshal 

5 buffer type is identified in step 306. A marshal buffer 
type may be identified by invoking an "id" method on the 
marshal buffer. An "id" method is used to obtain the 
marshal buffer type. After the marshal buffer type is 
identified, process control moves to step 309 where it is 

10 determined if the marshal buffer type identified in step 
306 is a type which is known to the subcontract associ- 
ated with the argument object reference. The marshal 
buffer type indicates both a supported protocol and a 
possible object reference encoding format. Typically. 

is there are four or five types of marshal buffers. These 
types include, but are not limited to, Common Data Rep- 
resentation (CDR) type used for an Internet Interopera- 
ble Protocol (HOP) transport and a door type, used for a 
door transport. 

20 Subcontracts require certain information to be 
transmitted within each object reference. This informa- 
tion typically relates to the quality of service which 
relates to the subcontract. A subcontract must encode 
the information in an encoding format suitable for the 

25 transport protocol which is to be used to transmit the 
information to a different domain. Hence, a subcontract 
uses the marshal buffer type to determine the encoding 
format to be used to encode the information. 

If the identified marshal buffer type is unknown, 

30 process flow moves to step 315 where an exception is 
thrown. The exception which is thrown may be returned 
in a location specified via the exception storage location 
descriptor. The exception indicates that it may not be 
possible to marshal the particular argument object refer- 

35 ence. When the exception is thrown, no attempt is made 
to marshal the argument object reference. Hence, 
potential errors which would arise from an attempt to 
marshal an object reference which may not be mar- 
shaled are avoided. If it is determined in step 309 that 

40 the identified marshal buffer type is known to the sub- 
contract associated with the argument object reference, 
the argument object reference is encoded in a form 
appropriate for the identified marshal buffer in step 312. 
Encoding information in a format appropriate to a 

45 marshal buffer type allows an instance of the same mar- 
shal buffer type on the receiving domain to determine 
the subcontract, or, more specifically the subcontract 
identifier, associated with the argument object refer- 
ence. The subcontract identifier is used to select an 

so appropriate subcontract specific unmarshal routine to 
decode, i.e. unmarshal, the information encoded by the 
marshal routine. As different subcontracts may encode 
different information into the same marshal buffer, it fol- 
lows that subcontracts perform the unmarshaling to 

55 extract the information. It should be appreciated that 
each subcontract encodes information using a set of 
well-known encoding formats such that the marshal 
buffer can find the subcontract identifier in the encoded 
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object reference. The encoding formats are determined 
from protocols supported by the marshal buffer, 
whereas the subcontract determines the information 
that is actually encoded. 

Referring next to FIG. 7, a method of unmarshaling 
an object reference that is one of or part of arguments 
to an invoked method in accordance with one embodi- 
ment of the present invention will be described. That is, 
the case of unmarshaling arguments which are object 
references as a part of step 222 of FIG. 4 will be dis- 
cussed. The process of unmarshaling an object refer- 
ence that is one of or part of arguments begins at step 
320, in which a peek method, or more specifically a 
PEEK_SCID method, is invoked on the marshal buffer 
to identify the subcontract associated with the argument 
object reference. Each marshal buffer has an associ- 
ated PEEK_SCID method, or function, which is specific 
to the marshal buffer type. Hence, since the marshal 
buffer type is dependent upon the mode of transport, or 
protocol, selected in step 202 of FIG. 4, it follows that 
the PEEK_SCiD method is also dependent upon the 
mode of transport used. The subcontract of the argu- 
ment object reference is determined when the subcon- 
tract identifier (SCID) is read from the marshal buffer 
using the PEEK_SCID method associated with the mar- 
shal buffer. In general, the PEEK_SCID method deter- 
mines the subcontract identifier for an object reference 
by looking at, or reading, the first four bytes of the object 
key of the object reference encapsulated in the marshal 
buffer. The object key of the object reference is such 
that the first four bytes of the object key will typically 
contain the subcontract identifier. However, the location 
of the object key within an encoded object reference, i.e. 
an object reference encapsulated in a marshal buffer, 
may vary depending on the protocol or transport used. 
Marshal buffers "know" how to locate an object key in an 
object reference, regardless of where the object key is 
located within the object reference. 

After a subcontract is identified, process control 
may proceed to step 322, which is the determination of 
whether the identified subcontract is an expected sub- 
contract. An expected subcontract is compiled into 
application code at start-up, and may be considered to 
be a "default" subcontract which is expected for the par- 
ticular argument object reference. If the identified sub- 
contract is the expected subcontract, the unmarshal 
method of the expected subcontract is called in step 
324, passing the marshal buffer and the corresponding 
subcontract identifier as arguments. Then, the process 
of unmarshaling an object reference that is one of or 
part of arguments to an invoke method is completed. If, 
on the other hand, it is determined in step 322 that the 
identified subcontract is not an expected subcontract, a 
search is made for the unmarshal method which corre- 
sponds to the identified subcontract from the subcon- 
tract registry in step 326. The subcontract identifier, 
which was located by the PEEK_SCID method in step 
320, is used as the key to locate the appropriate unmar- 



shal method in a subcontract registry. Subcontract reg- 
istries will be discussed below with respect to FIG. 9. 

The step of determining whether an identified sub- 
contract is an expected subcontract and the step of call- 

s ing the unmarshal method of the expected subcontract 
if it is determined that the identified subcontract is an 
expected subcontract make up an optional step 321. 
The use of expected subcontracts is intended to elimi- 
nate the need to search for an unmarshal method which 

w corresponds to an identified subcontract, in the event 
that an identified subcontract is an expected subcon- 
tract. If an identified subcontract is an expected subcon- 
tract, then the unmarshal method of the identified 
subcontract is known. In some embodiments, however, 

15 the comparison of an identified subcontract with an 
expected subcontract and the use of the expected sub- 
contract in step 321 may be eliminated. If the use of an 
expected subcontract is eliminated, process flow moves 
directly from the step of identifying a subcontract to step 

20 326, where a subcontract registry is used to find the 
unmarshal method which corresponds to the identified 
subcontract. 

After a search for an appropriate unmarshal 
method in a subcontract registry, process control pro- 

25 ceeds to step 328 where it is determined if an unmar- 
shal method which corresponds to the identified 
subcontract was found in the subcontract registry. If the 
determination is affirmative, i.e. an appropriate unmar- 
shal method has been found, the identified unmarshal 

30 method is called, with the marshal buffer as an argu- 
ment, in step 330. It should be appreciated that different 
subcontracts have different unmarshal methods due to 
the fact that each subcontract encodes information 
depending upon the particular quality of service it pro- 

35 vides. An embodiment of a subcontract specific unmar- 
shal routine will be described below with reference to 
FIG. 8. After the call to the unmarshal method, the proc- 
ess of unmarshaling an argument object reference is 
completed. On the other hand, if it is determined in step 

40 3 28 that a suitable unmarshal method was not found in 
the subcontract registry, an exception may be thrown in 
step 332. The exception may be returned in storage 
location specified by an exception storage location 
descriptor which is associated with the original call to an 

45 invoke method. 

Referring next to FIG. 8, a method of implementing 
a subcontract specific unmarshal routine to create an 
object reference, i.e., fat pointer or CORBA object refer- 
ence, in accordance with one embodiment of the 

so present invention will be described. That is, the call to 
the unmarshal method in step 330 of FIG. 7 will be 
described. The process begins at step 350 with the 
determination of whether the marshal buffer identifier 
(ID) may be recognized by the subcontract specific 

55 unmarshal routine that is to be implemented. If it is 
determined that the marshal buffer ID is not ^cogniza- 
ble, an exception is thrown in step 351 . The fact that the 
marshal buffer ID is not recognizable indicates that the 
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subcontract does not have knowledge regarding how to 
decode required information using the encoding format 
of the marshal buffer. If it is determined that the marshal 
buffer ID is recognizable, process control proceeds to 
step 352 where object reference data is extracted from 
the marshal buffer. The object reference data, or, specif- 
ically, argument object reference data, which is 
extracted is based upon the marshal buffer type. That is, 
the marshal buffer type dictates the type of object refer- 
ence data which is to be extracted and, more impor- 
tantly, the manner in which required information is 
extracted from a given encoding format. 

Alter argument object reference data is extracted, 
process control may proceed to step 354 where it is 
determined if a client representation exists for the object 
reference to be unmarshaled. As client representations 
may be associated with more than one object reference, 
it is possible that client representation which already 
exists may be suitable for the object reference to be 
unmarshaled. It should be appreciated that client repre- 
sentations differ depending upon the subcontract with 
which it is associated. That is, as client representations 
may be used to determine how object references are 
marshaled, client representations therefore vary 
according to the quality of service provided and, hence, 
the associated subcontract. If the determination is that a 
client representation exists for the object reference to be 
unmarshaled, an object reference is created in step 355 
using the already existing client representation. After 
the object reference is created, the process of imple- 
menting a subcontract specific unmarshal routine is 
complete. If the determination in step 354 is that a client 
representation does not exist for the object reference to 
be unmarshaled, process control proceeds to step 360 
where a client representation is created from the 
extracted object reference data. After a new client rep- 
resentation is created, an object reference is created 
using the new client representation in step 362. Alter 
step 362, the process of implementing a subcontract 
specific unmarshal routine is complete. 

Alternatively, the steps of searching for an existing 
client representation and creating an object reference 
using the existing client representation, i.e. steps 354 
and 355, which comprise an overall step 351, may be 
eliminated. The purpose of searching for and using an 
existing client representation in overall step 351 is to 
eliminate the step of creating a client representation 
from extracted object reference data in the event that a 
suitable client representation is already in existence. 
Although searching for and using existing client repre- 
sentations, if they are available, eliminates the creation 
of "extra" client representations, some embodiments 
may not include a search for existing client representa- 
tions. If the search for and use of client representations 
in not included, i.e. if step 351 is eliminated, after object 
reference data is extracted form the marshal buffer in 
step 352, process control proceeds to step 360 where a 
client representation is created from the extracted 



object reference data. Then, in step 362. ah object ref- 
erence is created using the new client representation, 
and the process of implementing a subcontract specific 
unmarshal routine is complete. 

5 On the server side of a client-server system, the 

selection of an appropriate dispatch routine for use in 
dispatching a request received on an end point to a sub- 
contract may be accomplished through the use of an 
end point specific dispatch registry. As mentioned 

w above with respect to FIG. 5, an end point specific dis- 
patch registry, or end point registry, associates subcon- 
tracts with closures which contain pointers to the 
dispatch routines which used to dispatch requests to an 
appropriate subcontract. In general, an end point regis- 

is try may be thought of as a listing of closures which are 
indexed using the suL contracts with which each closure 
is associated. 

As previously mentioned with respect to FIG. 7, a 
subcontract registry may be used to select the appropri- 
ate ate unmarshal function to use in order to unmarshal an 
object reference, given a subcontract identifier. FIG. 9 is 
a diagrammatic representation of a subcontract registry 
data structure 600 in accordance with one embodiment 
of the present invention. Subcontract registry data 

25 structure 600, or, simply, subcontract registry 600, 
stores information that associates a particular quality of 
service with a unique subcontract identifier and with a 
subcontract client representation create function. Sub- 
contract registry 600 registers information pertaining to 

30 subcontracts in a tabular form, and makes available 
subcontracts within a system available for searching. 
The tabular form is advantageous in that it allows any 
number of implementations to be associated with a par- 
ticular subcontract. It should be appreciated that 

35 although a predetermined number of permutations of 
. features within a system are possible, subcontract reg- 
istry 600 may identify only a subset of these possible 
subcontracts that have been implemented within the 
distributed object system. Subcontract registry 600 may 

40 be implemented as a hash table, linked list or any other 
suitable data structure. 

Subcontract registry 600 includes a subcontract 
identifier (SCID) column 602, an associated quality of 
service list column 604, a subcontract client representa- 

45 tion create function column 606, and pointers to other 
functions 608. Each row 610 of subcontract registry 600 
is termed a subcontract meta object and, by way of 
example, may be implemented as a C++ object. In the 
embodiment shown, a plurality of subcontract meta 

so objects 612, 614 and 616 are provided in subcontract 
registry 600. The first subcontract meta object 212 has 
a subcontract identifier of "1" and will herein be identi- 
fied as Subcontract 1 . Subcontract 1 lists the following 
features for its quality of service: clean shutdown, secu- 

55 rity, persistence and server activation. The name-value 
pairs in this quality of service list indicate that a clean 
shutdown will not be implemented, an authentication 
protocol using MD5 will be used for security, and per- 
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sistence is turned on. Subcontract 1 has a pointer to its 
associated subcontract client representation create 
function, client representation create 1,' in subcontract 
client representation create function column 606. A plu- 
rality of pointers to various other functions associated 5 
with each subcontract meta object in other function col- 
umn 608 include pointers to an unmarsha! function, a 
destringify function, and a bad server identifier handler. 

The second subcontract meta object 614 shown in 
subcontract registry 600 is the subcontract meta object w 
associated with the subcontract identified as subcon- 
tract 2. The quality of service list for this subcontract 
indicates that server activation is present. The third sub- 
contract meta object 216 indicates that the subcontract 
identified as subcontract 3 will allow for transactions, is 
clean shutdowns, and server activation. 

Subcontract registry 600 will typically have a group 
of associated functions that are used to organize and 
access the registry. By way of example, the associated 
functions may include an Add function, a Find function, 20 
a Get_First function and a Get_Next function-. The Add 
function may be used to add a new quality of service to 
the table. In the described embodiment, the Add func- 
tion takes as arguments a subcontract identifier and a 
subcontract meta object. A Find function takes a sub- 25 
contract identifier as an argument and returns the sub- 
contract meta object associated with that identifier. The 
functions Get_First and Get_Next are used to iterate 
over a subcontract registry, as for example subcontract 
registry 600, thereby searching it completely for a par- 30 
ticular quality of service, and returning the appropriate 
meta object. When a client wishes to make a call to a 
particular server object, subcontract registry 600 may 
be used to look up the subcontract identifier associated 
with that server object. Once the appropriate subcon- 35 
tract identifier has been located, the appropriate sub- 
contract client representation create function is called in 
order to create a client representation that may be refer- 
enced by an object reference.. 

The present invention as described above employs 40 
various process steps involving data stored in computer 
systems. These steps are those requiring physical 
manipulation of physical quantities. Usually, though not 
necessarily, these quantities take the form of electrical 
or magnetic signals capable of being stored, trans- 45 
ferred, combined, compared, and otherwise manipu- 
lated. It is sometimes convenient, principally for reasons 
of common usage, to refer to these signals as bits, val- 
ues, elements, variables, characters, data structures, or 
the like. It should be remembered, however, that all of so 
these and similar terms are to be associated with the 
appropriate physical quantities and are merely conven- 
ient labels applied to these quantities. 

Further, the manipulations performed are often 
referred to in terms such as identifying, running, or com- 55 
paring. In any of the operations described herein that 
form part of the present invention these operations are 
machine operations. Useful machines for performing 



the operations of the present invention include general 
purpose digital computers or other similar devices. In all 
cases, there should be borne in mind the distinction 
between the method of operations in operating a com- 
puter and the method of computation itself. The present 
invention relates to method steps for operating a com- 
puter in processing electrical or other physical signals to 
generate other desired physical signals. 

The present invention also relates to an apparatus 
for performing these operations. This apparatus may be 
specially constructed for the required purposes, or it 
may be a general purpose computer selectively acti- 
vated or reconfigured by a computer program stored in 
the computer. The processes presented herein are not 
inherently related to any particular computer or other 
apparatus: In particular, various general purpose 
machines may be used with programs written in accord- 
ance with the teachings herein, or it may be more con- 
venient to construct a more specialized apparatus to 
perform the required method steps. The required struc- 
ture for a variety of these machines will appear from the 
description given above. 

In addition, the present invention further relates to 
computer readable media that include program instruc- 
tions for performing various computer-implemented 
operations. The media and program instructions may be 
those specially designed and constructed for the pur- 
poses of the present invention, or they may be of the 
kind well known and available to those having skill in the 
computer software arts. Examples of computer reada- 
ble media include, but are not limited to, magnetic 
media such as hard disks, floppy disks, and magnetic 
tape; optical media such as CD-ROM disks; magneto- 
optical media such as optical disks; and hardware 
devices that are specially configured to store and per- 
form program instructions, such as read-only memory 
devices (ROM) and random access memory (RAM). 
Examples of program instructions include both machine 
code, such as produced by a compiler, and files contain- 
ing higher level code that may be executed by the com- 
puter using an interpreter. 

FIG. 10 illustrates a typical computer system in 
accordance with the present invention. The computer 
system 700 includes a processor 702 (typically referred 
to as a central processing unit, or CPU) that is coupled 
to memory devices including primary storage device 
704 (typically a read only memory, or ROM) and primary 
storage device 706 (typically a random access memory 
,or RAM). As is well known in the art, ROM 704 acts to 
transfer data and instructions uni-directionally to the 
CPU and RAM 706 is used typically to transfer data and 
instructions in a bi-directional manner. A mass memory 
device 708 is also coupled bi-directionally to CPU 702 
and provides additional data storage capacity. Mass 
memory device 708 may be used to store programs, 
data and the like and and is typically a secondary stor- 
age medium such as a hard disk that is slower than pri- 
mary storage devices 504, 506. Mass memory device 
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708 may take the form of a magnetic or paper tape 
reader or some other well-known device. It will be 
appreciated that the information retained within mass 
memory device 708, may, in appropriate cases, be 
incorporated in standard fashion as part of RAM 706 as 
virtual memory. A specific mass storage device such as 
a CD-ROM 714 may also pass data uni-directionally to 
the CPU. 

CPU 702 is also coupled to one or more input/out- 
put devices 710 that may include, but are not limited to, 
devices such as video monitors, track balls, mice, key- 
boards, microphones, touch -sensitive displays, trans- 
ducer card readers, magnetic or paper tape readers, 
tablets, styluses, voice or handwriting recognizers, or 
other well-known input devices such as, of course, other 
computers. Finally, CPU 702 optionally may be coupled 
to a computer or telecommunications network using a 
network connection as shown generally at 712. With 
such a network connection, it is contemplated that the 
CPU might receive information from the network, or 
might output information to the network in the course of 
performing the above-described method steps. The 
above-described devices and materials will be familiar 
to those of skill in the computer hardware and software 
arts. 

Although only one preferred embodiment of the 
present invention has been described, it should be 
understood that the present invention may be embodied 
in many other specific forms without departing from the 
spirit or the scope of the present invention. In the 
described embodiment, a subcontract registry has been 
described. It will be apparent that the subcontract regis- 
try can be widely varied within the scope of the present 
invention. Further, steps involved with methods of mar- 
shaling and unmarshaling argument object references 
may be reordered. Steps may also be removed or 
added without departing from the spirit or the scope of 
the present invention. 

Additionally, in some situations, marshal and 
unmarshal methods associated with a common object 
may be combined into a single method. For instances in 
which the marshal and unmarshal methods are identi- 
cal, the addition of an argument in the function call could 
be used to specify whether marshaling or unmarshaling 
is desired. For instances in which the marshal and 
unmarshal methods are distinct, a new function could 
be created to perform both methods. This new function 
could include an argument to the function call which 
would specify whether the method desired was mar- 
shaling or unmarshaling. If a single function represents 
both marshaling and unmarshaling, in typecode and 
descriptor data structures with pointers to marshal and 
unmarshal methods, one pointer may be used to point 
to the single function. A boolean value or a flag may be 
implemented into the descriptor data structures which 
would indicate whether marshaling or unmarshaling is 
desired by the descriptor data structure. Therefore the 
described embodiments should be taken as illustrative 



and not restrictive, and the invention should be defined 
by the following claims and their full scope of equiva- 
lents. 

5 Claims 

1 . A method of unmarshaling an argument object ref- 
erence that is at least a part of an argument in an 
invocation request encapsulated within a marshal 

w buffer, the argument object reference including a 
subcontract identifier, the method comprising the 
steps of: 

a) identifying a subcontract associated with the 
75 argument object reference by reading the sub- 
contract identifier in the argument object refer- 
ence, wherein the subcontract identifying step 
is accomplished by the marshal buffer; 

b) accessing a subcontract registry using the 
20 identified subcontract identifier as a key to 

identify an unmarshal method associated with 
the identified subcontract identifier, the subcon- 
tract registry accessing step being accom- 
plished by the subcontract identified by the 
25 subcontract identifier; and 

c) calling the identified unmarshal method 
passing the marshal buffer as an argument to 
the call, wherein the identified unmarshal 
method unmarshals the argument object refer- 

30 ence. 

2. A method as recited in claim 1 further comprising 
the step of determining whether the identified sub- 
contract identifier is the same as an expected sub- 

35 contract identifier, wherein; 

when it is determined that the identified sub- 
contract identifier is not the same as the 
expected subcontract identifier, steps (b) and 

40 (c) are performed; and 

when it is determined that the identified sub- 
contract identifier is the same as the expected 
subcontract identifier, steps (b) and (c) are not 
performed and the method further comprises 

45 the step of calling an expected unmarshal 

method that corresponds to the expected sub- 
contract identifier. 

3. A method as recited in any of claims 1 or 2 wherein 
so the step of identifying the subcontract identifier is 

accomplished by invoking a peek method on the 
marshal buffer. 

4. A method as recited in any of claims 1-3 wherein 
55 the object reference further includes a server iden- 
tifier, an implementation identifier, and a user key. 

5. A method of marshaling an argument object refer- 



14 



27 



EPO 817 022 A2 



28 



ence that is to be an argument or part of an argu- 
ment encapsulated within a marshal buffer, the 
object reference including a subcontract identifier, 
the method comprising the steps of; 

5 

a) invoking a marshal method of a client repre- 
sentation in the argument object reference 
passing the marshal buffer as an argument to 
the marshal method; 

b) identifying the marshal buffer type; and w 

c) determining whether the identified marshal 
buffer type is known to a subcontract identified 
by the subcontract identifier of the argument 
object reference, wherein when it is determined 
that the identified marshal buffer type is known is 
to the identified subcontract, the argument 
object reference is encoded into a form appro- 
priate for the identified marshal buffer type. 

6. A computer readable medium having programmed 20 
instructions for unmarshaling an argument object 
reference that is at least a part of an argument 
encapsulated within a marshal buffer, the argument 
object reference including a subcontract identifier, 

the computer readable medium having pro- 25 
grammed instructions arranged to: 

a) identify a subcontract associated with the 
argument object reference by reading the sub- 
contract identifier in the argument object refer- 30 
ence, wherein the subcontract identifying step 

is accomplished programmed instructions 
associated with the marshal buffer; 

b) access a subcontract registry using the iden- 
tified subcontract identifier as a key to identify 35 
an unmarshal method associated with the iden- 
tified subcontract identifier, the subcontract 
registry accessing step being accomplished by 
programmed instructions associated with the 
subcontract identified in the subcontract iderrti- 40 
fier; and 

c) call the identified unmarshal method passing 
the marshal buffer as an argument to the call, 
wherein the identified unmarshal method 
includes programmed instructions to unmar- 45 
shal the argument object reference. 

7. A computer readable medium as recited in claim 6 
further comprising programmed instructions for: 

50 

determining whether the identified subcontract 
identifier is the same as an expected subcon- 
tract identifier, the programmed instructions 
further being arranged to perform steps (b) and 
(c) when it is determined that the identified sub- 55 
contract identifier is not the same as the 
expected subcontract identifier, and not per- 
form steps (b) and (c) when it is determined 



that the identified subcontract identifier is the 
same as the expected subcontract identifier; 
and 

calling an expected unmarshal method that 
corresponds to the expected subcontract iden- 
tifier when it is determined that the identified 
subcontract identifier is the same as the 
expected subcontract identifier. 

8. An argument object reference unmarshaler for use 
in a distributed, client server computing system, the 
argument object reference unmarshaler compris- 
ing: 

a marshal buffer for receiving a distributed 
request that includes an argument object refer- 
ence having a subcontract identifier; 
a peeking mechanism associated with the mar- 
shal buffer that peeks at the subcontract identi- 
fier associated with the argument object 
reference, the peeking mechanism being 
arranged to make an unmarshaling request call 
to a subcontract associated with the subcon- 
tract identifier; 

a subcontract registry having entries corre- 
sponding to a plurality of different subcontracts, 
the subcontract registry being arranged to 
identify an unmarshal method associated with 
each different subcontract; 
a subcontract registry searching mechanism 
associated with the subcontract for searching 
the subcontract registry using the subcontract 
identifier found by the peeking mechanism as a 
key to identify the unmarshal method associ- 
ated with the argument object reference; and 
a call dispatcher for calling the identified 
unmarshal method passing the marshal buffer 
as an argument to the call, whereby the identi- 
fied unmarshal method unmarshals the argu- 
ment object reference. 

9. A computer readable medium having programmed 
instructions for marshaling an argument object ref- 
erence that is at least a part of an argument encap- 
sulated within a marshal buffer, the argument object 
reference including a subcontract identifier, the 
computer readable medium having programmed 
instructions arranged to: 

a) invoke a marshal method of a client repre- 
sentation in the argument object reference 
passing the marshal buffer as an argument to 
the marshal method; 

b) identify the marshal buffer type; and 

c) determine whether the identified marshal 
buffer type is known to a subcontract identified 
by the subcontract identifier of the argument 
object reference, wherein when it is determined 
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that the identified marshal buffer type is known program code for effecting the following steps within 

to the identified subcontract, the argument the computer system: 

object reference is encoded into a form appro- 
priate for the identified marshal buffer type. 

5 

10. An argument object reference marshaler for use in 
a distributed, client/server computing system; the 
argument object reference marshaler comprising: 

a marshal buffer for encapsulating a distributed w 
request; 

an identifying mechanism associated with the 
marshal buffer that identifies the marshal buffer 
type; and 

a marshaling routine which uses the marshal is 
buffer type to determine an appropriate method 
to use for marshaling information in an argu- 
ment object reference 



a) identifying a subcontract associated with the 
argument object reference by reading the sub- 
contract identifier in the argument object refer- 
ence, wherein the subcontract identifying step 
is accomplished by the marshal buffer; 

b) accessing a subcontract registry using the 
identified subcontract identifier as a key to 
identify an unmarshal method associated with 
the identified subcontract. 



1 1. An argument object reference marshaler as recited 20 
in claim 10 wherein the argument object reference 
constitutes an entire argument in the invocation 
request. 

12. A method of unmarshaling an argument object ref- 25 
erence that is at least a part of an argument in an 
invocation request encapsulated within a marshal 
buffer, the argument object reference including a 
subcontract identifier, the method comprising the 
steps of: 30 



a) identifying a subcontract associated with the 
argument object reference by reading the sub- 
contract identifier in the argument object refer- 
ence, wherein the subcontract identifying step 35 
is accomplished by the marshal buffer; 

b) determining whether the identified subcon- 
tract identifier is the same as an expected sub- 
contract identifier; 

c) when it is determined that the identified sub- 40 
contract identifier is the same as the expected 
subcontract identifier, calling an expected 
unmarshal method that corresponds to the 
expected subcontract identifier, the unmarshal 
method calling step being accomplished by the 45 
subcontract identified by the subcontract identi- 
fier. 



13. A computer program product comprising a compu- 
ter-usable medium having computer-readable code so 
embodied thereon for unmarshaling an argument 
object reference that is at least a part of an argu- 
ment in an invocation request encapsulated within 
a marshal buffer, the argument object reference 
including a subcontract identifier, the argument 55 
object reference defined within a distributed cli- 
ent/server based computer system, the computer 
program product comprising computer-readable 
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